Communication is the sine qua non of culture and collaboration. Despite its importance, it is often done reflexively with little conscious thought. Humans tend to use language loosely and in the company of a large number of assumptions about what others may understand. But, the task of language is to encode relations between entities, properties, and other aspects of the world to convey, process, and assign meaning as well as manage and resolve ambiguity. Whoa! Speaking of communication – what did that say?
Our language is supposed to enable us to take what we are seeing and thinking, give it meaning, and then send that meaning out to others. It’s what we use to develop “mindshare” with others. It’s critical to understanding and collaborating with others. The world of systems engineering is no exception to this.
When the stakes are high, communication must be at its best. Conveying meaning – and specifically the meaning intended by the sender – requires care and precision. After all, the goal is to spark a mental picture in the mind of the receiver that matches the mental picture held by the originator of the message. As noted before in discussing the siren songs of systems engineering, If I say “horse,” the word springs from a mental model of the animal. I might also draw a picture of my “horse.” The picture isn’t a horse or even a model of a horse, but it shows a subset of information about my model (four legs, tail, mane, etc.). The point here is that the picture (or view) came from my model. That picture of my mental “horse” model is how I communicate my idea of “horse.”
By and large, the communication about our systems engineering designs takes place through representations of the design. In one way or another, we create pictures of the design to share with others. In model-based systems engineering (MBSE) we refer to these as representations of the model. The representations become the vocabulary of systems engineering. As David Long recently pointed out, “Models are the foundation of communication by which the sender crafts her description and the receiver understands the message.” They make up the language with which we convey the designs we create.
Productive and receptive vocabularies
When we look to the study of language, we encounter the contrasting concepts of “productive” and “receptive” vocabularies. Our productive vocabulary is composed of the words we can use to produce messages. On the other hand, our receptive vocabulary includes all the words we can recognize and understand in receiving messages from others.
When we “speak” or otherwise transmit ideas, we need to use a productive vocabulary that matches the receptive vocabulary of our intended audience as closely as possible. When that happens, we produce messages that are received and understood by the audience. If we use a productive vocabulary that isn’t a part of the receptive vocabulary of the audience, our meaning will not be conveyed.
Understanding this principle became the basis for the use of Native American “Code-Talkers” (Choctaw and Cherokee in World War I and Lakota, Meskwaki, Comanche, Seminole, and Navajo in World War II). Their languages were unintelligible to the enemy because the productive vocabulary of the Code Talkers was completely outside the receptive vocabulary of the Germans and Japanese. [As an interesting side note, after the use of Choctaw and Cherokee in World War I, Hitler sent a team of anthropologists to study Native American languages before the outbreak of World War II. The knowledge of this venture kept the use of the Code Talkers in World War II largely confined to the Pacific Theater out of fear the German effort had been successful.]
It was very clever to use this total lack of lingual overlap to successfully thwart enemy understanding of wartime communication. But to do so unintentionally in our day-to-day commerce is not nearly so clever. How does that happen?
Failing to understand our audience
First, we fail to recognize the breadth of our audience. Systems engineers have a wide variety of stakeholders. The differences in their backgrounds and experience creates differences in their receptive vocabularies. A hospital administrator schooled in process improvement using Total Quality Management (TQM) and Lean Six Sigma to understand her processes is not likely to successfully decipher technical engineering diagrams without some effort and information. Presenting a process design to her in such diagrams amounts to asking her to learn a foreign language.
Too often we overcomplicate the processes of systems engineering with technical jargon, acronyms, and undecipherable views. We need to respect our audience and the breadth of our constituency. That means communicating in ways that suit our audience.
The pitfalls of adopting exclusive standards
Second, we make it even harder to communicate by adopting exclusive “standards” for our communication. The virtue of standardizing our communication is that a given symbol then carries an unambiguous meaning. But this is a two-edged sword. In order to standardize the communication, we must standardize both the transmission and reception. Transmitting in a “standard” framework that is not understood by the audience – or a segment of the audience – isn’t helpful. If I don’t speak Italian, it doesn’t matter how impeccable your Italian vocabulary is – I still can’t understand it, and your untranslated message is not received.
In and of themselves, standards are not bad. But they are limiting. If we standardize on a language spoken by software engineers, those who speak TQM will be excluded. At best, it is confusing. At worst it is exclusive. Almost by definition, standards are effective only to the extent that the audience is aware of them and assents to their use. If the goal of our communication is broad appeal, standards can be self-defeating.
How, then, should we approach our communication? Just as the acquisition of a broad vocabulary will enable us to speak to a wide audience in different situations, the wider our choice of representations, the more widely we can accurately communicate context, problems, and the corresponding solutions to those who need to understand them. We need to seek the broadest possible choice of representations so that we have the right “word” when and where we need it.
Vitech’s modeling tools, CORE™ and GENESYS™, embody this principle by making it possible to choose from a wide variety of representations to communicate the information that makes up the system model and its greater context. Instead of confining the representations to a narrow subset or “standard” set of diagrams and documents, these tools produce a variety of visualizations that allow system engineers to communicate their ideas to software engineers accustomed to UML/SysML and to business process owners familiar with flow charts and “swim lanes.”
We should be cautious about the veneration of standards as a blessing per se. Yes, we need to be precise in our messaging, but not at the expense of excluding segments of our audience. Highly specialized jargon is not necessary to successful communication. Russell Ackoff, a pioneering systems thinker, pointed out that “Unless people can express themselves well in ordinary (language), they don’t know what they are talking about.” (He said “ordinary English,” but the same is true in any language.) Knowing our subject well enough to talk about it in basic terms is the antidote to a too narrow expression of our ideas that limits our communication to those who know the code.
Sacrificing communication power in the name of standards is a step on the way to impoverishing our communication. We need to offer the world a rich variety of communicative possibilities – possibilities that will speak to the variety in our constituency. Scientific, engineering, social, and political problems all need what systems engineering has to offer. But if we can only offer our solutions in a limited set of “standard” expressions, we will find it difficult to make the case for them in the world beyond our usual haunts.
